Previous iteration of the API favoured returning hex from the interface
and working with a bunch of hex strings. What this leads to is

- Extra unneeded computation. Pretty much all libraries work with
binary data which meant a round-trip hex conversion everytime we produced data.

- String validation code is present everywhere. We have to ensure that
all the characters are hex and if they start with '0x' or even '0X' we
trim those out. This is a lot of extra work that is avoided by working
in binary.

I've relegated most of the dynamic containers to those that need
dynanism (like serializing a transaction to RLP since we have variable
data payloads). Everything else, especially hashes and cryptography are
now represented with fixed byte buffers.

All APIs generate binary data first, _then_ there're helper functions
that convert the binary to hex if hex is needed (e.g. serialising to JSON).

This ensures that we trim leading zeros off the string such that
the primitive checks for converting into a U64 that do a bounds check
against the length of the string vs the largest possible number to
be stored work more permissively with large 0 padded strings.

We only use keccak out of cncrypto, so this removes all the other junk,
and minimally modifies the keccak implementation to build in ethyl
without needing other files (and updates the keccak signature to match
oxen-core's, which changed the last argument from int to size_t).

This also puts it under a src/ethyl-keccak subdirectory so that when we
are building with cncrypto from oxen-core, we won't find the local
version in our include path and instead get the appropriate headers via
oxen-core when building with oxen-core's cncrypto.